Release Refactoring

View article on our wiki

• Release planning works to maximise Product Market Impact and thereby business Throughput by reconciling feature priorities and calendar dates with quantified Release Goals across the Epic Landscape.
• Business, design and technical stakeholders self-organize into Product Squads and Portfolio Councils to collaborate on tradeoffs for this purpose using Leadership as a Service and Open Book Management.
• When solution assumptions fail, market conditions change, new business, design or technology constraints are identified, or other significant learnings show up, feature priorities and release plans must be adapted to them immediately to maintain Throughput.

Therefore,

Release Refactoring is a rapid consensus game that enables quick numeric trade-offs between different feature-sets while respecting calendar dates and budget limits for a release goal.

1. This is a game for the entire Product Squad - business stakeholders make the decisions but design and tech stakeholders question them and answer questions.
2. Using the Royal Cod prioritization derived by Business Bingo, lay out all available Features in columns grouped by Epic.
3. Pick the first column. Pick the feature at the top of the column. Let business stakeholders say whether the Release Goal can be satisfied for this Epic without including that feature. If they disagree, use Leadership as a Service to resolve the matter.
4. Continue down the column, feature by feature, until the business stakeholders agree that one of the features isn’t critical for the Release Goal for this Epic.
5. Call all the features above that one bronze and all the ones below them silver.
6. Now ask the business stakeholders whether any of the silver features could be deferred till the following release without impacting the Release Goal. Call the ones that can be deferred “gold”.
7. Total how many feature points are in each of bronze, silver and gold levels for that Epic.
8. Total how much ROI are in each of bronze, silver and gold levels for that Epic.
9. Repeat the above steps for all columns.
10. If you’re working to create a release plan for a particular date, determine how many feature points correspond to that constraint. Now simply select the combination of bronze, silver and gold groups with the maximum ROI within that number.
11. Let stakeholders do some fine tuning and trade-offs of features from different epics to respect COD issues. But make certain they start with the bronze/silver/gold tranches so keep this conversation manageable.
12. If fitting to a continuous delivery funding model rather than a specific date, use Getting Features Done instead.
13. Keep the refactoring board on an Information Radiator to assure continuous alignment of authorities and for context for the next Release Refactoring session.

Release Refactoring is played whenever new features are added to the Acceptance Matrix, whenever Sprint Planning indicates a feature’s budget is blown, or whenever the PO calls for it. Because this is such a quick game it’s also possible to play using set-based Simple Design in an R&D Stream mode to evaluate alternative product plans to evaluate possible responses to changes in market conditions.